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Remarks 

Claims 1-26 are presently before the Examiner. 



riaim Keiectior * - ^ T T S P S 102(e) 

Claims 13-26 have been rejected under 35 U.S.C. § 102(e) as being anticipated by 
Chandra et al. (U.S. Patent No. 6.058,389, herein after referred to as "Chandra"). Applicants 
respectfully traverse the rejection of claims 13-26 for the following reasons. 

Chandra discloses a message queuing system integrated into a database system, where 
a queue is an ordered list of messages and the messages are requests for processing by an 
application. A queue table holds a set of queues, and each queue table is implemented as a 
database table within the relational database system. Each queue table can contain multiple 
queues each having multiple messages. Each row of a queue table represents a message in a 
queue ofthe queue table. Some of me columns in a queue table are meta-data describing the 
queue. (Col. 7, Lines 4-12 and Fig. 2) Chandra teaches that each application has a different 
view of the same queue, in order.that a message can be dequeued and deleted from an 
application' s view while the same message remains in the queue view of another appUcation. 
(Col. 12, Lines 1 1-16) Thus, in Chandra, multiple views, or copies, ofthe same queue are 
stained, in order that more than one application can access the same message. Chandra 
further teaches that whenamessage is dequeuedby an apphcation, a reference count ofthe 
message stored in the queue table is decremented, and that when the reference count reaches 
zero, the message is then either deleted or archived (Col. 20, Lines 4(M9). 

mclaim 13 ofthe present application, the recited "system for dehvery of irJbnnation 
to multiple consumers" comprises "an formation queue conmnsmg one or more m 
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queue records, each satf information queue record comprising information to be accessed by 
one or more consumers". Chandra does not teach, disclose or suggest the "system for 
delivery of information to multiple consumers" recited in claim 13 as in Chandra, each 
application, rather than accessing the same queue of messages, maintains its own view, or 
copy, of the queue of messages. Thus, in Chandra, each application accesses a message from 
its own individual view, or copy, of the queue. The mechanism of Chandra teaches away 
from the present invention of claim 13 whose goal, inter alia, is to provide a system for 
delivery of information to multiple consumers that requires a minimum amount of memory to 
maintain. 

Claims 14-20 depend from claim 13 and are believed to be allowable over Chandra for 
at least the same reasons as discussed with reference to claim 13. 

Claim 21 recites a "system for the delivery of messages to multiple consumers- 
comprising "a history table comprising one or more history records, each of said one or more 
history records comprising a message identification, a consumer identiacarion and a message 
state identification". Chandra teaches an Enqueue Options parameter which is a data structure 
associated with a message that is enqueued. An Enqueue Options parameter for a message 
stores, inter alia, a correlation identifier, which is a value that identifies a message to a user of 
the system, a recipient list, which identifies applications or processes to which messages are 
to be forwarded when dequeued, and a state parameter that specifies the state of the message 
at the time of a dequeue operation. (Col. 13, Line 13 to Col. 15, Line 25) The Enqueue 
Options parameter for a message does not disclose, teach or suggest a history table 
comprising one more history records, each history record "comprising a message 
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21. 

In an Equeue Options parameter, there are no history records each comprising a 
me ssage identification; in Chandra, the Enqueue Options parameter has one single correlation 
identifier. In an Enqueue Options parameter, there are no history records each comprising a 
consumer identification; in Chandra the Enqueue Options parameter comprises a recipient list, 
which is not the same as a set of history records each comprising a consumer identification. 
In an Enqueue Options parameter, there are no history records each comprising a message 
state identification; in Chandra the Enqueue Options parameter has one single state parameter. 
Moreover, while Chandra does disclose mamtaming a message even after it is dequeued, in 
order to maintain a history of what h* been done (Col. 19, Lines 28-30), retaining a message 
to maintain a history of what has been done does not disclose, teach or suggest a "history 
table comprising one or more history records, each of said one or more history records 
comprising a message identification, a consumer identification and a message state 
identification," as recited in claim 21. T^, claim 21 is not Closed, taught or suggested by 

Chandra- 

Claim 22 depends from claim 21 , and thus, for the same reasons discussed with regard 
to claim 21, claim 22 is not disclosed, taught or suggested by Chandra. 

Claim 23 recites a "method for multiple consumers to access information in a non 
first-in first-out, prescribed order, said information comprising one or more pieces of 
information, a fist piece of information stored b a first locauon," the method com P risin S 
"providing access to said first piece of information to a first consumer of said multiple 
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consumers; indicating in a second location ft. said first consumer has accused said firs, 
piece of informal providing access <o said first piece of information to a second consumer 
of said multiple consumers; artd indicating in a third location that said consumer has accessed 
said first piece of information". As previously discussed, in Chandra, when amessage is 
dequeued, or otherwise accessed, by an application, a reference count of the message in the 
mreuetabU is decremented. (Col. 20, Lines 40^9) Thus, to Chandra, when a firs, message is 

eppticanon). ft. same reference count is decremented. Thus, Chandra, does no. disclose, 
reach or suggest a memod comprising "indicating in a second location that said first consumer 
has accessed said 6m piece of information- and "Seating in a third location that said 
secondcoi^erbasaccessedsaidfu^^ to discussing claim 23. the 

Office Acta cite, CoL 30, Line 30 to CoL 32, Line 60 of Chandra. Applicant respectfully 
point out that this portion of Chandra is concerned with creating tire oueue able in rhe 
relational daabase, and is no. concerned with consumers, or application,, accessing 
u^rmatior. Formesereaso.*a>an^ 
recited in claim 23. 

Claims 24-26 depend from claim 23, and thus, for the same reasons discussed with 
regard to claim 23, claims 24-26 are not disclosed, taught or suggested by Chandra. 

P otions - ^ IT S P. S 103(a) 

Claims 1-12 of the present application have been rejected under 35 U.S.C. § 103(a)as 
being unpatentable over Capps (U.S. Patent No. 5,666,502, herein after referred to as 
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"Capps"). Applicants respectfully traverse the rejection of claims 1-12 for the following 

reasons. 

Capps teaches a data input technique for a computer that provides a user with a 
historical list of potential choices for the data input (Col. 2, Lines 17-19) In Capps, a 
historical list is displayed to the user so that the user can input data by selecting an item from 
the historical list being displayed. (Col. 2, Lines 20-23) In Capps, the historical list of the 
most recently and/or frequently used data values for the data field that the user is entering data 
for are provided to the user. (Col. 2, Lines 31-33) 

Claim 1 of the present application recites a "method for managing information to be 
accessed by multiple consumers, said information comprising one or more information 
records, said information records to be accessed by said multiple consumers in a specified 
order, each said information record comprising data to be accessed by a consumer". Capps 
fails to disclose, teach or suggest the method recited in claim 1 of the present application. In 
Capps, the history list does not have "information records to be accessed by said multiple 
consumes in a specified order". In Capps, any user can access any of the data in a history list 
in any order. In Capps, the history list is simply a list of items, any one of which auser can 
access when they are inputting data to a data field related to the respective history list. Thus, 
Capps does not disclose, teach or suggest the method of claim 1. 

Claim 1 also recites "updating a history table, said history table comprising one or 
more history records, each said history record comprising a message state field, said updating 
comprising setting said message state field in a history record corresponding to said consumer 
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to mdicate said consumer accessed said data". The Office Action correctly acknowledges that 
Capps does not disclose or teach a "message state field". 

Moreover, a message state field is not suggested by, or obvious in light of, Capps. In 
Capps, a history table is maintained from which a history list is produced. (Col. 1 1 , Lines 14- 
15) A history table in Capps contains a string/pointer to the data of a respective history list, 
the last time the corresponding data item was accessed by a user of the history list, and the 
overall number of times that users have accessed the corresponding data in the history list. 

(Col. 11, Lines 21-30 and Fig. 6A) 

Capps does not disclose, teach or suggest updating a history table comprising one or 
more history records where the updating comprises setting a message state field in a history 
record corresponding to a consumer to indicate the consumer accessed the data. Capps is not 
concerned with keeping track of which consumer accessed what data; all Capps is concerned 
with is how many times anyone accessed a particular data item. Thus, Capps does not 
disclose,teachorsuggesta"am^ 

table comprising one or more history records, each said history record comprising a message 
state field, said updating comprising setting said message state field in a history record 
corresponding to said consumer to indicate said consumer accessed said data," as recited in 
claim 1. Capps, therefore, does not disclose, teach or suggest the method recited in clann 1. 

Claims 2-12 depend from claim 1 and thus, for the same reasons discussed withregard 
to claim 1, claims 2-12 are not disclosed, taught or suggested by Capps. 
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Conclusion 

Based upon the foregoing remarks, it is respectfully submitted that the application is 
in condition for allowance, and a Notice of Allowance is respectfully requested. Should the 
Examiner have any questions or comments, they are invited to call the undersigned at the 
below-listed number; 

Respectfully submitted, 

LYON & LYON LLP 
Attorney for Applicants 



Dated: rvtnher 24. 2001 



633 West Fifth Street, 47* Floor 
Los Angles, California 90071-2066 
(408) 993-1555 



LySn Y> flfciCernan 
Reg. No. 41,986 
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